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Representing IMS Messages as XML Documents 

BACKGROUND OF THE INVENTION 
Field of the Invention 

The present invention relates generally to transaction processing systems. 
More particularly, the present invention relates to a system and method for 
representing IMS messages as XML documents. 

Related Applications 

This application claims the benefit of U.S. Patent Application No. 
60/151,479, filed August 30, 1999, for "IMS Messages in XMI," which is 
incorporated herein by reference. 

Identification of Copyright 

A portion of the disclosure of this patent document contains material subject 
to copyright protection. The copyright owner has no objection to the facsimile 
reproduction by anyone of the patent document or the patent disclosure, as it 
appears in the Patent and Trademark Office patent file or records, but otherwise 
reserves all copyright rights whatsoever. 
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Relevant Technology 

With the explosive growth of the Internet, most of the world's computer 
systems are now interconnected or capable of being interconnected. However, in 
order to share data, the systems need to understand each other's data formats. In 
recent years, the computer industry has evolved at such a rapid pace that systems 
developed only a few years apart use vastly different and incompatible formats. 
Such incompatibility problems tend to increase with the "age" differences of the 
systems. 

The Information Management System (IMS) is one of the oldest and perhaps 
the most popular transaction processing (TP) systems. A TP system supervises the 
sharing of resources for concurrently processing multiple transactions, such as 
queries to a database. Anyone who has ever used an ATM, rented a car, or booked 
a flight, has probably used IMS. 

IMS was developed by IBM in the 1960's as a inventory tracking system for 
the U.S. moon landing effort. Today, interfacing IMS with newer systems, 
particularly with systems of different manufactures over the Internet, is 
problematic. 

As illustrated in Figure 1, an IMS 10 typically includes two major 
components: an IMS Transaction Monitor (IMS/TM) 12, which is responsible for 
scheduling, authorization, presentation services and operational functions, and a 
hierarchical database 14, DL/1. Both components are independently configurable. 
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For example the IMS/TM 12 can use a relational database, such as DB/ 2, rather than 
DL/1. The various components of an IMS 10 communicate via the MVS operating 
system 16. 

As illustrated Figure 2, the architecture of IMS is divided into four regions: 
a message processing region (MPR) 20, a batch message processing (BMP) 22 region, 
an interactive fast path (IFP) 26 region, and an IMS control (IMSCTL) 24 region. 
The MPR 20 is used to execute message-driven applications 18. Execution of 
applications 18 in this region 20 is triggered by incoming messages, such as those 
received from a terminal. 

By contrast, applications 18 in the BMP 22 are not message driven. They are 
usually scheduled to run at times of low system activity, such as nights and 
weekends. Typically, such applications 18 perform a number of predefined 
operations, after which they immediately terminate. 

The IFP 24 allows fast and simple requests to the hierarchical database 14. 
Applications 18 operating in the IFP 24 bypass the normal scheduling mechanism, 
providing relatively fast response times. In general, IFP applications 18 stay 
resident even if they are not needed. 

The IMSCTL 26 is responsible for overseeing all TP tasks, as well as for 
controlling all dependent regions (e.g., MPR 20, BMP 22, and IFP 24). Essentially, 
the IMSCTL 26 has three main responsibilities: telecommunications, message 
scheduling, and logging/ restart. 
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For example, as illustrated in Figure 3, the IMSCTL 26 controls one or more 
connected terminals 28, sending and receiving messages to and from the terminals 
28. Moreover, the IMSCTL 26 logs all transactions in order to provide the capability 
of undoing non-committed transactions in the event of a system failure. 

In addition, every time the IMSCTL 26 receives an input message 30 from a 
terminal 28, it schedules an application 18 to process the message 30. The IMSCTL 
26 identifies the desired application 18 and puts the message 30 in the application's 
message queue 32. The application 18 processes the message 30 and responds to the 
originating terminal 28 by placing an output message 30 in the terminal's message 
queue 34. 

As illustrated in Figure 4, an input message 30 typically includes the 
following fields: 

LL Length of the message segment. 

ZZ Reserved for IMS. 

TRANCODE Transaction code that identifies the application 18. 

Text Message text sent from the terminal 28 to the 

application 18. 

The structure of an output message 30 is similar, except that the TRANCODE field 
is missing. 

In general, messages 30 belong to one particular IMS application 18. When 
the application 18 is implemented, the format of the message 30, including the types 
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and lengths of its fields, must be defined. The format of a message 30 is referred to 
herein as a message definition 38. Message definitions 38 may be implemented 
using various programming languages, such as COBOL, assembler, PL/ 1 and 
Pascal. For example, the message definition 38 illustrated in Figure 4 is 
implemented in COBOL. 

Unfortunately, IMS messages 30 are in a proprietary format, whereas the 
Internet is based on open standards, such as the HyperText Markup Language 
(HTML), a variant of the extensible Markup Language (XML). As a result, 
interfacing IMS with remote systems via the Internet can be difficult. Accordingly, 
what is needed is a system and method for representing IMS messages 30 in an 
open, interchangeable format, such as XML. 
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SUMMARY OF THE INVENTION 

The present invention solves many or all of the foregoing problems by 
providing a system and method for representing IMS messages as XML documents. 
In one aspect of the invention, a method includes generating an XML document 
template from an IMS message definition and merging an IMS message with the 
generated template to produce a corresponding XML document. 

In another aspect, a process of generating the XML document template 
includes obtaining an IMS message definition; obtaining a DTD for representing 
arbitrary IMS message definitions; compiling the IMS message definition with an 
option configured to produce an associated data (Adata) file; and parsing the Adata 
file using the DTD to generate an XML document template corresponding to the 
IMS message definition. 

In various embodiments, the IMS message definition may include program 
source code in a language selected from the group consisting of COBOL, PL/ 1, 
Assembler, and Pascal. Additionally, the Adata file may include at least one IMS 
message definition in a relatively language independent format compared with the 
program source code. 

In another aspect, a process of obtaining the DTD may include creating a 
UML object model for representing arbitrary IMS message definitions; and 
processing the object model using an XMI utility to generate the DTD. 
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In still another aspect, a process of merging the XML document template 
with the IMS message may include identifying a placeholder within XML document 
template for receiving a corresponding value from the IMS message; reading the 
value from the IMS message; and inserting the value into a location within the XML 
document template indicated by the placeholder. In certain embodiments, the 
placeholder may be implemented as an XML tag. 

In still another embodiment of the invention, a placeholder may include an 
associated tag for indicating that a corresponding value exists within the IMS 
message. Additionally, a placeholder may include an associated tag for indicating 
the size of the corresponding value within the IMS message. 

In yet another aspect, a system for representing IMS messages as XML 
documents may include a template generation module configured to generate an 
XML document template from an IMS message definition; and a merging module 
configured to merge an IMS message with the generated template to produce a 
corresponding XML document. 

In various embodiments, the template generating module may include a 
compiler configured to compile an IMS message definition with an option 
configured to produce an associated data (Adata) file; and a parser configured to 
parse the Adata file using a DTD for representing arbitrary IMS message definitions 
to generate an XML document template corresponding to the IMS message 
definition. 
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In certain embodiments, the system may also include a modeling tool 
configured to create a UML object model for representing arbitrary IMS message 
definitions; and an XMI utility for generating the DTD from the UML object model. 

These and other objects, features, and advantages of the present invention 
will become more fully apparent from the following description and appended 
claims, or may be learned by the practice of the invention as set forth hereinafter. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is more fully disclosed in the following specification, 
with reference to the accompanying drawings, in which: 

Figure 1 is a schematic block diagram of an Information Management System 

(IMS); 

Figure 2 is a schematic block diagram of IMS processing regions; 

Figure 3 is a schematic block diagram of message processing within an IMS; 

Figure 4 is a schematic block diagram of the structure of IMS messages; 

Figure 5 is a schematic block diagram of a technique for representing an IMS 
message definition in XML according to an embodiment of the invention; 

Figure 6 is a schematic block diagram of an alternative technique for 
representing an IMS message definition in XML according to an embodiment of the 
invention; 

Figure 7 is a schematic block diagram of a system for representing IMS 
messages as XML documents according to an embodiment of the invention; 

Figure 8 is a schematic block diagram of a UML object model of an IMS 
message definition according to an embodiment of the invention; 

Figure 9 is a class hierarchy of a parser according to an embodiment of the 
invention; 
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Figure 10 is a schematic block diagram of a technique for representing an IMS 
message definition as an XML document template according to an embodiment of 
the invention; 

Figure 11 is a schematic flowchart of a method for representing IMS messages 
as XML documents according to an embodiment of the invention; 

Figure 12 is a schematic flowchart of a process for generating an XML 
document template from an IMS message definition according to an embodiment 
of the invention; and 

Figure 13 is a schematic flowchart of a process for merging an XML 
document template with an IMS message according to an embodiment of the 
invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 



Certain presently preferred embodiments of the invention are now described 
with reference to the Figures, where like reference numbers indicate identical or 
functionally similar elements. The components of the present invention, as 
generally described and illustrated in the Figures, may be implemented in a variety 
of configurations. Thus, the following more detailed description of the 
embodiments of the system and method of the present invention, as represented in 
the Figures, is not intended to limit the scope of the invention, as claimed, but is 
merely representative of presently preferred embodiments of the invention. 

Throughout the following description, various system components are 
referred to as "modules" or the like. In certain embodiments, these components 
may be implemented as software, hardware, firmware, or any combination thereof. 

For example, as used herein, a module may include any type of computer 
instruction or computer executable code located within a memory device and/ or 
transmitted as electronic signals over a system bus or network. An identified 
module may include, for instance, one or more physical or logical blocks of 
computer instructions, which may be embodied within one or more objects, 
procedures, functions, or the like. 

The identified modules need not be located physically together, but may 
include disparate instructions stored at different memory locations, which together 
implement the described logical functionality of the module. Indeed, a module may 
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include a single instruction, or many instructions, and may even be distributed 
among several discrete code segments, within different programs, and across 
several memory devices. 



Obtaining Message Definitions from an Application 

As noted, IMS messages 30 are defined within a corresponding application 
18. As such, in order to generate an XML document that represents a message 30, 
a technique for obtaining a message definition 38 from an application 18 would be 
highly desirable. 

In certain embodiments, the format of a message 30 may be directly obtained 
from an application's source code using a specially-designed parser. For example, 
the following is a typical COBOL message definition 38, which may be analyzed by 
the parser: 

01 INPUT-MSG. 

02 IN-LL PICTURE IS 9(2). 

02 IN-ZZ PICTURE IS 9(4). 

02 IN-TRAN PICTURE IS X(10). 

02 IN -COMMAND PICTURE IS X(8). 

02 TEMP - COMMAND REDEFINES IN -COMMAND . 

04 TEMP-IOCMD PIC X(3) . 

04 TEMP-FILLER PIC X(5) . 

However, COBOL has a very complex syntax. For example, variable 
definitions in COBOL may include complex dependencies, making the source code 
of message definitions 30 difficult to parse. Moreover, because each language is 
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different, a different parser would typically be required for each different 
programming language, such as PL/I and Assembler. 

Accordingly, in one embodiment of the invention, message definitions 38 are 
obtained from a System Associated Data (SysAdata) file 78 (illustrated in Figure 7), 
which is produced by various compilers 76 when the "adata" option is specified. 
In essence, the SysAdata file 78 is a compiler-generated debugging aid. It contains 
information about the structure of a program, the contained data, the data flow 
within the program, and the system in which the program operates. 

One reason for relying the SysAdata file 78 rather than the application source 
code 74 is that a single parser may be used for different programming languages. 
For example, PL/ 1 compilers and some high-level assemblers also generate 
SysAdata files 78. Although some differences exist in the SysAdata files 78 
produced by different compilers 76, such differences may be compensated for by 
those skilled in the art. 

A record of the SysAdata file 78 generally includes the following two 
sections: 

1. a 12 byte header section, which has the same structure for all record 
types; and 

2. a variable length data section, which varies by record type. 

To extract a message definition 38 from a SysAdata file 78, not all record types are 
needed. For example, in one embodiment, only the Common Header Section, the 

-Page 13- 

IBMNo. ST9-99-146 



1 

2 
3 
4 
5 
6 
7 
8 
9 

10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 



Compilation Unit Start/ End Record, and the Symbol Record are used. These 
records are described in greater detail below. 

The format of the various records within the SysAdata file 78 are shown in 
Tables 1-3, with the following abbreviations being used to indicate data types: 

c indicates character (EBCDIC or ASCII) data; 

h indicates 2-byte binary integer data; 

f indicates 4-byte binary integer data; 

x indicates hexadecimal data or 1-byte binary integer data with the 



Common Header Section 

The Common Header Section contains, among other things, a record code 
that identifies type and length of the record. The 12 byte header section has the 
following format: 



length of the number given behind the data type. 



Table 1 



Field 



Size Description 



Language Code 



xl 16 
17 
40 



High Level Assembler 
COBOL on all platforms 
PL/ 1 on supported platforms 



Record type 



h2 



xOOOO 
xOOOl 
x0002 



Job Identification record 
AD ATA Identification record 
Compilation unit start/ end 



xOOlO 



record 

Options record 
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x 0020 


External Svmbol record 


v 0074 


PflT<!P T"TPP TPPOtH 
X CIA 1 ICC A CCU1 \A. 


x0030 


Token record 


x0032 


Source Error record 


x0038 


Source record 


x0039 


COPY REPLACING record 


x0042 


Symbol record 


x0044 


Symbol Cross-Reference record 


x0046 


Nested Program record 


x0060 


Library record 


x0090 


Statistics record 


x0120 


EVENTS record 



Adata architecture level x 1 3 Definition level for the header 

structure 



Flag 


xl 


1. Adata record integer are in Little 

Endian (Intel) format 

1 This record is continued in the 

next record 

1111 11.. 

Reserved for future use 


Adata record edition 
level 


xl 


Used to indicate a new format for a specific record 
type. Usually zero. 


Reserved 


c4 


Reserved for future use 


Adata field length 


h2 


The length in bytes of the data following the header. 


Compilation Unit Start /End Record 



The Compilation Unit Start/ End Record is the second and the last record in 



the SysAdata file 78. The 8 byte record uses the following format: 

Table 2 



Field Size Description 

Type h 2 Compilation unit type, which can be one of the 

following: 
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xOOOO 
xOOOl 



Start compilation unit 
End compilation unit 



Reserved c 2 Reserved for future use 

Reserved f 4 Reserved for future use 



Symbol Record 

The Symbol Record contains all of the information needed to understand the 
structure of a message definition 38 that has been compiled into a Sys Adata file 78. 
Only the fields that are used in a presently preferred embodiment of the invention 
are listed in Table 3. For simplicity, Table 3 only indicate the size, and not the 
position, of the fields. The position of the fields can be determined from the source 
code of Appendix A by those skilled in the art. 

Table 3 



Field 


Size 


Description 




Symbol ID 


f4 


Unique ID of symbol 


Level 


f4 


True leve number of symbol (or relative level 






number of a 


data item within a structure). Level 






is in the range of 01-49, 66 (for rename items), 77, 






or 88 (for condition items). 


Symbol Type 


xl 


x68 


Class name 






x58 


Method name 






x40 


Data name 






x20 


Procedure name 






xlO 


Mnemonic name 






x08 


Program name 






x81 


Reserved 


Symbol Attribute 


xl 


Numeric 
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x2 
x3 


Alphanumeric 
Group 

note: other attributes are ignored 


Clauses 


xl 


For numeric, alphanumeric and group items: 

1 Value 

.1 Indexed 

..1 Redefines 

...1 .... Renames 
.... 1... Occurs 

1.. Has Occurs Keys 

1. Occurs Depending on 

1 Occurs in Parent 

note: other values are ignored 


Data Flagsl 


xl 


1 Redefined 

.1 Renamed 

..1 Synchronized 

...1 .... Implicity redefined 
.... 1... Date field 

1.. Implicit redefines 

1. FILLER 

1 Level 77 


Size 


f 4 


the size of this data item. The actual number of 

bytes this item occupies in storage. 

Also referred to as the "Length Attribute/ 7 

2 


Parent ID 


f4 


The symbol ID of the immediate parent of the 
symbol being defined. 


Redefined ID 


f4 


The symbol ID of the data item, that this item 
renames. 


Symbol Name Length h 2 


The number of characters in the symbol name. 


The source code of the application 18 and the SysAdata file 78 contain 
essentially the same information about the message definition 38. However, in 
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order to read the source code, a parser would need to understand a subset of the 
COBOL language. 

By contrast, the Sy s Adata file 78 has a clearly defined format, each bit having 
a definite meaning. Consequently, the SysAdata file 78 may be easier to read and 
understand, and the corresponding parser more simple and easy to implement. 

As shown in Figure 7, a compiler 76 produces the SysAdata file 78 when it 
is able to compile an application source code file 74 without major errors. 
Accordingly, a system and method in one embodiment of the invention verifies that 
the compilation completed with a return code of 4 or less. Analysis can still proceed 
if "Information" and "Warning" messages are generated, but there should be no 
"Error", "Severe error", or "Termination" messages. 

In certain embodiments, compiling a subset of the application 18, i.e. the 
message definition 38, itself, is advantageous. For example, a particular message 
definition 38 may be extracted from the application's source code 74 or a copy file 
and copied into the working-storage section of a COBOL source file template for 
separate compilation. In certain embodiments, a message definition extractor 75 
may be provided for this purpose, which may extract a user-specified message 
definition 38 from the source code 74 of an application 18. The extractor 75 may 
create a valid source file for a compiler 76 as illustrated below: 

IDENTIFICATION DIVISION. 

PROGRAM- ID. EXAMPLE-MSG. 
ENVIRONMENT DIVISION. 
DATA DIVISION. 
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WORKING- STORAGE SECTION. 



01 



INPUT -MSG. 



02 



02 



02 



02 



IN- COMMAND 



IN-ZZ 



IN-TRAN 



IN-LL 



PICTURE IS 9 (2) . 

PICTURE IS 9 (4) . 

PICTURE IS X(10) 

PICTURE IS X(8) . 



02 



TEMP-COMMAND REDEFINES IN -COMMAND . 



04 



04 



TEMP- FILLER 



TEMP-IOCMD 



PIC X(3) . 
PIC X (5) . 



PROCEDURE DIVISION. 
STOP RUN. 

Of course, it would also be possible to read a SysAdata file 78 from the 
compilation process of an entire application 18. However, since one application 18 
may include a plurality of messages definitions 38 in the working-storage section, 
a user would need to make a choice as to which message definition 38 to use. 

Generating a Document Type Definiton (DTD) for IMS Messages 

In order to represent IMS messages 30 in XML, generating a Document Type 
Definition (DTD) 54 is highly desirable. Various techniques may be used to create 
the DTD 54. For example, in certain embodiments, a different DTD 54 may be 
created for each particular message 30. Such a DTD 54 would allow any XML 
parser to understand the structure of the associated message 30. In alternative 
embodiments, a generic DTD 54 for arbitrary messages 30 may be created. These 
two options are fundamentally different and are described more fully in the 
following sections. 



IBM No. ST9-99-146 



-Page 19- 



1 

2 
3 
4 
5 
6 
7 
8 
9 

10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 



One DTD Per Message Definition 

As illustrated in Figure 5, each data entry 53 (e.g., variable or group) in the 
message definition 38 may be directly represented by an element in the DTD 54. 
Each element may have one or more attributes, which contain information about 
the data entry. 

The benefit of this technique is that the corresponding XML documents 44 are 

relatively simple. For example, an XML document 44 corresponding to the message 

definition 38 of Figure 5 may include the following: 

<IN-LL length="2" type="Numeric" >55</IN-LL> 
<IN-ZZ length="4" type="Numeric" >102</IN-ZZ> 

< I N - LAS TNAME length="10" type=" Alphanumeric" >Meyer</IN-LASTNAME> 

Although this approach results in a straightforward DTD 54 and simple XML 
documents 44, it has two major disadvantages. First, no tool can be effectively used 
to create the DTD 54. Rules governing DTD 54 creation typically need to be 
implemented in a parser. Second, because different names may be used for 
elements and attributes, no generalized techniques for reading and writing 
corresponding XML documents 44 may be provided. 

Generic DTD for all Messages 

In an alternative embodiment, as illustrated in Figure 6, a single, generic DTD 
54 may be used for all IMS messages 30. In this case, each data entry 53 from a 
message definition 38 may be represented as a "Dataltem" 55. The structure of a 
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Dataltem 55 is defined in the DTD 54 of Appendix C, and is described in greater 
detail below. 

The generic DTD 54 approach offers several advantages. First, the generic 
DTD 54 may be created using standard tools from a UML object model, as explained 
below. Second, an XMI utility, such as IBM's XMI Toolkit™, may be used to provide 
generic access methods for reading and writing XML documents 44. Third, the 
generic DTD 54 is relatively language independent (compared to source code 74), 
such that message definitions 38 implemented in Assembler, PL/ 1, or the like can 
be presented in the same way. Finally, the DTD 54 may be maintained and updated 
in a common location. 

Using the generic DTD 54 approach, as illustrated in Figure 6, a message 
definition 38 may be transformed into an XML document template 58 that 
represents the format of a particular message 30. Later, a merging module 80 may 
be used to merge the actual IMS message 30 with the template 58 to create an XML 
document 44 that represents the message 30. This process is described in greater 
detail below. 

Modeling IMS Message Definitions 

Figure 7 illustrates a system 60 for generating the above-described DTD 54 
and XML document templates 58 according to an embodiment of the invention. The 
system 60 may include a Uniform Modeling Language (UML) modeling tool 62. 
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The UML modeling tool 62 may be used to produce a generic UML object model 64 
to represent arbitrary IMS messages 30. In one embodiment, the UML modeling 
tool 62 is Rational Rose™, a visual modeling tool available from Rational Software. 

UML is a language for specifying, visualizing, constructing, and 
documenting software systems, in addition to business models and the like. UML 
is capable of representing the static, dynamic, environmental, and organizational 
aspects of almost any system. 

In order to generate a DTD 54, the abstract structure of the message 30 should 
be modeled. As noted above, in one embodiment, each data entry 53 of the 
message definition 38 may be represented as a Dataltem 55, whether the entry is a 
group, a redefined variable, or a normal variable. For example, if a data entry 53 
is a group, all group members are also Dataltems 55, but they are one level lower 
in the object hierarchy of the model. 

Figure 8 illustrates a UML object model 64 of an IMS message definition 38 
according to one embodiment of the invention, as implemented by the UML 
modeling tool 62. In various embodiments, the model 64 includes a Dataltem class 
65 for representing each data entry 53 of the message definition 38. An instance of 
the Dataltem class 65 stores data retrieved from a Symbol Record of a SysAdata file 
78, as explained below. 

In various embodiments, the Dataltem class 65 includes a number of 
attributes: 
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Name: 



Contains the name of the data entry 53 represented by an instance of 



the class. 



Type: 



Contains the Symbol Attribute. Valid values are defined in Class 



tSymbolAttribute (see Table 3). 



Length: 



Contains the length of the Dataltem instance. If the data entry 53 is 



a group or the root element, the length is added to the length of all of 



the children. 



has Value: Indicates if the Dataltem instance is used to store actual data or used 



As illustrated in the obj ect model 64 of Figure 1 0, a Dataltem instance may have zero 
or more children. The children are also Dataltem instances and are contained within the 
parent. Every Dataltem instance has zero or one parent. Accordingly, the parent-child 
hierarchy of the object model 64 may be used to model the hierarchical structure of IMS 
message definitions 38. 

In various embodiments, the classes tSymbolAttribute, tString and tBoolean may 
serve as type classes for the Dataltem attributes. As such, attributes of the class 
tSymbolAttribute become possible values of the Dataltem.Type attribute. 

Referring again to Figure 7, the system 60 may also include an XML Metadata 
Interchange (XMI) utility 66, such as XMI Toolkit™, available from IBM. XMI is an 



to group other Dataltems together. It also indicates whether the 



<Value> tag is present. 



Value: 



Contains the value of the variable. 
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open standard released by the Object Management Group (OMG) for simplifying 
the exchange of data and metadata between different products from different 
vendors. IBM's XMI Toolkit is written entirely in Java and offers interfaces to 
facilitate incorporation into other projects or products. However, languages other 
than Java may be used in various implementations. 

In one embodiment, the XMI utility 66 automatically generates the DTD 54 
from the UML object model 64. The following is a portion of a DTD 54 for IMS 
messages 30 according to an embodiment of the invention. A more complete DTD 54 
including XMI-specific additions may be found in Appendix C. 

< ! ELEMENT Dataltem (Dataltem. Name? , Datal tern. Type? , Dataltem. Length? , 

Dataltem . hasValue? , Dataltem . Value? , XMI . extension* , 
Dataltem. parent? , Dataltem . child* ) ? > 

< I ATTLIST Dataltem 

%XMI . element . att ; 
%XMI.link.att; > 

< ! ELEMENT Dataltem. parent (Dataltem)? > 

<! ELEMENT Dataltem. child (Dataltem)* > 

<! ELEMENT Dataltem. Name (# PCDATA | XMI . reference) * > 

<! ELEMENT Dataltem. Type EMPTY > 

< ! ATTLIST Dataltem. Type xmi. value ( Root | Numeric | Alphanumeric | Group 
) # REQUIRED > 

<! ELEMENT Dataltem. Length (# PCDATA | XMI . reference) * > 
< ! ELEMENT Dataltem. hasValue EMPTY > 

< ! ATTLIST Dataltem. hasValue xmi. value ( true | false ) # REQUIRED > 
<! ELEMENT Dataltem. Value (# PCDATA | XMI . reference) * > 
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In addition, the XMI utility 66 may create a plurality of Java XMI document 
access classes 68, which are used to read and write XML files based on the DTD 54, 
as described more fully below. 

Generating XML Document Templates 

Referring again to Figure 7, the system 60 may also include a SysAdata parser 72, 
which uses the generated DTD 54 and XMI classes 68 to parse the SysAdata file 78. As 
previously noted, the SysAdata file 78 may be generated by a compiler 76, such as IBM's 
Visual Age™ COBOL compiler, while compiling an application 18 from source code 74. 
In one embodiment, the output of the parser 72 is an XML document template 58 that 
represents the format of a particular IMS message 30. As used herein, the parser 72 and the 
compiler 76 may be referred to collectively as a template generation module 77. 

In alternative embodiments, however, the template generation module 77 may not 
include the compiler 76. For example, the template generation module 77 may directly parse 
and transform the message definition 38 into an XML document template 58. 

As noted, the XMI utility 66 may also produce Java XMI classes 68 to read and write 
XML files. Accordingly, the parser 72 may be implemented in Java, although the invention 
is not limited in this respect. Figure 9 illustrates a class hierarchy 83 of the parser 72 
according to an embodiment of the invention. The source code and a brief description of the 
classes may be found in Appendices A and B, respectively. 

Figure 10 further illustrates the above-described process of generating an XML 
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document template 58 from an IMS message definition 38. As illustrated, the 
<DataItem.Value> tags are empty since no values from an IMS message 30 have been 
supplied. Later, as described below, the IMS message 30 will be merged with the template 
58 to create the XML document 44. The <DataItem.Value> tags function essentially as 
"place holders" for receiving corresponding values from the IMS message 30. 

Referring now to Figure 11, a schematic flowchart illustrates a method 90 for 
representing IMS messages 30 as XML documents 44. In one embodiment, the 
method 90 begins by generating 92 an XML document template 58 for the message 
30 to be represented. Thereafter, the method 90 continues by merging an IMS 
message 30 with the XML document template 58 to produce the XML document 44. 

Figure 12 provides further details of the process 92 of generating the XML 
document template 58. In one embodiment, the process 92 begins by extracting 96 
a message definition 38 from the source code 74 of an IMS application 18 or an 
associated copy file. Thereafter, the process 92 continues by compiling 98 the 
extracted message definition 38 using the "adata" option. Finally, the process 92 
concludes by parsing 100 the resulting Sys Adata file 78 with the DTD 54 to produce 
the XML document template 58. 

Figure 13 shows the process 94 of merging the IMS message 30 with the XML 
document template 58 in additional detail. The process 94 may begin by reading 
102 the next Dataltem 55 from the XML document template 58. Thereafter, a 
determination 104 is made whether the <DataItem.hasValue> tag of the Dataltem 
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55 has a "true" value. If not, the method returns to step 102 to read the next 
Dataltem 55. 

Otherwise, the process 94 may continue by reading 106 a value (e.g. a 
quantity of data) from the IMS message 30 equal in size to the value of the 
<DataItem.Length> tag. For example, if the <DataItem.Length> tag has a value of 
5, the process 94 may read 106 the next 5 bytes from the IMS message 30 in one 
embodiment. Thereafter, the process 94 continues by inserting 108 the value read 
from the message 30 into the XML document template 58, i.e. within the 
<DataItem.Value> tags of the corresponding Dataltem 55. 

A determination 110 is then made as to whether more Dataltems 55 remain 
in the XML document template 58. If so, the process 94 returns to step 102 to read 
the next Dataltem 55. Otherwise, the process 94 is complete. 

Based on the foregoing, the present invention offers a number of advantages 
over conventional IMS interface systems. For example, the present invention allows 
proprietary IMS messages 30 to be represented using openly interchangeable 
documents, such as XML documents 44. The documents 44 may comply with the 
latest XMI standard, which enables an IMS 10 to exchange data with a variety of 
XMI-enabled devices, such as Web browsers and the like. 

Importantly, XML documents 44 may be easily converted for display on a 
variety of computing platform using the emerging XML Style Language (XSL) 
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standard. As such, the XMI to IMS interface is capable of replacing all other 
interfaces between IMS and products from other vendors. 

Additionally, because the SysAdata file 78 is used in one embodiment to 
obtain IMS message definitions 38, the invention is not limited to a single 
programming language as in conventional approaches. For example, a single 
parser 72 may be used with COBOL, PL/ 1, and other compilers. 

The present invention may be embodied in other specific forms without 
departing from its scope or essential characteristics. The described embodiments 
are to be considered in all respects only as illustrative and not restrictive. The scope 
of the invention is, therefore, indicated by the appended claims rather than by the 
foregoing description. All changes which come within the meaning and range of 
equivalency of the claims are to be embraced within their scope. 

What is claimed is: 
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